@ms-cloudpack/bundler-plugin-rollup
Provides a Cloudpack bundler abstraction around the Rollup bundler.
Usage
async function bundlePackage(options)
import { bundlePackage } from '@ms-cloudpack/bundler';
async function start() {
const result = await bundlePackage({
packagePath: process.cwd(),
outputPath: path.join(process.cwd(), 'dist'),
outputType: 'library',
});
console.log(result);
}
start();
bundlePackage
options
Name | Type | Description |
---|
packagePath | string | Path to the package root where package.json lives. |
force | boolean | Bypasses the cache to create bundles. |
hashFrom | "package-version" | "git" | Determines how the cache key is computed for bundle results. |
output | "library" | "app" | |
Return object
Name | Type | Description |
---|
stats | | |
outputMap | | |
Details
The Cloudpack bundler abstraction is simple and constrained on purpose:
- Consume a standard package (app or library) with a minimum set of requirements.
- Emits standard ESM bundle.
- Leverages package.json and convention as much as possible:
This library has only 2 output modes:
- library mode - produces a bundle of source which externalizes dependencies and is consumable by the target (browser or node) which
can resolve the dependencies through an import maps in the browser or through module resolution in node. The source is unminified.
- production mode - produces a bundle of source which includes dependencies and is also similarly consum
Package requirements
Discovering entry points
Entry points are discovered by analyzing the package.json. This ensures only explicit entries are bundled.
ESM output
Considerations
Leverage existing task runners
Under the hood, if we want to separate the process into multiple steps, we may consider using task helpers like just-scripts
or heft
to execute things in the right order. This might help
Splitting the "bundle" abstraction into pre/bundle/post steps